%% by Enrique
A Relational Model in our context can be seen as a set of relations (later
mapped to tables) form which we know:
\begin{itemize}
  \item name of the relation (that will become name of the table). To which we
  can refer to as $Table_i$.
  \item a set of attributes names (the table columns) belonging to specific
  domains. We can denote them as $[col_{i_1},\ldots,col_{i_n}]$, and we can also
  refer to the value of a column as $col_{i}[idx]$ where it would represent
  the value of $col_{i}$ of the tuple with index $idx$ in the table. 
  \item a subset of those attributes that will work as primary key. Denoted by
  $[col_{j_1},\ldots,col_{j_n}] \subseteq [col_{i_1},\ldots,col_{i_n}]$
\end{itemize}

We need to perform Object Relational Mapping to be able to obtain a Relational
Schema. In general we can follow the RMAP algorithm described for a Conceptual
Modeling course \cite{montali} that focuses on providing a result with less 
possible tables and redundancy avoidance. In  addition we also generate 
some constraints and derivations rules that can be present in the  Conceptual
model specification.

Each tuple belonging to a relation in our relational model will be identified by
a primary key, the combination of some specific atributes values that is unique
and therefore can be used to identify each tuple, but also we can have other
uniquenes constraints. We can also have cardinality constraints to restrict how
many times a certain combination of atributes occurs. All this constraints can
be represented with a general cardinality constraint:
\[
min\leq \#\{(Table_{i}.col_1,\ldots,Table_{i}.col_n)\}\leq max
\]

According to the conceptual model, some columns of our table are optional and
can allow null values. Normally the RMAP tries to minimize the number of
optional columns then we can assume that the number of of mandatory columns is
greater than the number of optional columns, then makes sense to add to the
constraints of the Relational Model the columns that are optional, then the rest
is assumed to be mandatory:

\[
optional(Table_{j}.col_i)
\]

Foreing keys are constraints that relates rows from one table to rows of another
table. For each foreing key relation we can define a subset constraint to
track it:
\[
Table_i.[col_{i_1},\ldots,col_{i_n}] \subseteq
Table_j.[col_{j_1},\ldots,col_{j_n}] 
\]

Note that we can also define that the populations are equal, using the
previously defined constraint but for practical reasons we are interested in
defining them in another kind of constraint:
\[
Table_i.[col_{i_1},\ldots,col_{i_n}] =
Table_j.[col_{j_1},\ldots,col_{j_n}] 
\]

Now, the final result of the RMAP algorithm is a consistent Relational Model but
maybe it is not what we call human readable, but how can we obtain a human
readable  model? Sadly from the Conceptual Models as we know them we cannot 
deduce which columns would be more informative to the client. In general the 
Conceptual Models needs to be extended in such a way that let us specify which 
columns are meant to be in a table (other than the ones the algorithm includes
to represent the model in a relational schema), even if they are redundant
because we can find that information in another table.

Let us analyze the example of an information system in which we control the
people that works in a company and who of them work in pairs. If we identify a
person by the SSN then in the RMAP procedure the pairs relation will contain
only two columns of SSN numbers but for a datasheet it is not very informative,
therefore it would be better to also include the names columns, or it might
also be of interest to the client to include the profession columns.

In general those redundant columns we add needs to be consistent with the other
table that constrains the information.  So we can specify that by writing a way
to compute their values:
\[
Table_i[col_{i'_1},\ldots,col_{i'_m}] \mbox{~with~}
Table_i.[col_{i_1},\ldots,col_{i_n}]
\mbox{~is~} 
\]
\[
Table_j[col_{j'_1},\ldots,col_{j'_m}] \mbox{~with~}
Table_j.[col_{j_1},\ldots,col_{j_n}]
\]
where $col_{i'_k}$ in $Table_i$ are the columns that take values from columns
$col_{j'_m}$ in table $Table_j$ when  $(\forall k)
col_{j_k}[idx]=col_{i_k}[idx]$.

When we have concepts defined in an extensional way we can also add the
following constraint:
\[
Table_i \mbox{~is~}
[(v_{1_1},\ldots,v_{1_n}),\ldots,(v_{k_1},\ldots,v_{k_n})]
\]

So far this model would allow us to show the information that the user is
interested in, and do it in a consistent way by having constraints to ensure the
consistency and also by having way to specify the value for redundant
attributes. 
